1. Field of the Invention
The present invention relates, in general, to software upgrades in computer systems and in distributed computer networks, and, more particularly, to a system and method for analyzing an existing computer system or network to quantify potential difficulties in performing an upgrade from a current version to a newer version of the software in each or a combination of the four categories, namely operating system or operating environment, development tools, middleware, and application programs. This invention further describes tools to analyze binaries or executable programs and other features of the computer system or network to quantify or better categorize such difficulties or risks, and to effectively report such quantified risks in a manner that is readily understandable by and useful to a manager of the computer system in determining whether to make a move to the newer software version and what initial or preparation steps to perform as part of the upgrade.
2. Relevant Background
New versions of software are released and distributed regularly by software developers to provide new and enhanced software features and to address the ongoing innovations and changes in related software, in available hardware, in networking and communication technologies (such as the Internet), and in security requirements and technologies. In the software industry, the current trend is to provide updates or new versions for key software products every six months, with each new version incorporating improvements and enhancements. Hence, an important task facing computer system operators is determining when and how to make the move from an older version of a software product to a newly released version.
Unfortunately, the decision of when and how to perform a software upgrade is complicated by a number of factors. Computer systems can be very large and complex including multiple networks, varied geographic locations, and hundreds or thousands of computer and electronic devices. A large and daunting task faced by most computer system operators is to fully understand the hardware and software that make up their current system. Different levels of software are used in most computer systems, including the four categories, namely operating system or environment software, development tool software, middleware software, and application software. Software in each of these levels may be upgraded individually or in combination often with the functioning, via interfaces, shared libraries, and the like, of a particular software product affecting or relying on the operation of software products in other levels. In other words, an upgrade or change to one software product most likely will affect the operation of other software products.
An important consideration for a system manager making upgrade decisions is maintaining binary compatibility for applications built to run on earlier releases. When binaries (or executables) are not compatible or are at risk of incompatibility with an upgraded version of software, the software customer or system manager faces a dilemma. Even though a new release may be desirable from a function standpoint, the software customer may not desire to make the move if a large investment is required to revise and update numerous existing binaries to work within the upgraded environment and may decide to postpone one or more upgrades. Often worse, the software customer may simply fear the unknown or potential problems if risks of incompatibility or failure of existing binaries after the upgrade are not well defined or understood.
System managers face a challenge in balancing the demands for a highly effective and functional computer system, that urges toward performing each available upgrade, against expectations of a highly-available system and network with no or little downtime and architectural continuity, that urges toward only performing lower or no risk upgrades. System managers want to make software upgrade that can be performed smoothly without sacrificing existing investments in built binaries and other levels of software. Extensive testing is typically performed by software upgrade providers to minimize risks of implementing an upgrade but the mission critical nature of a customer's system or environment with multi-vendor supplied software applications requires careful planning, risk and benefit assessment, and detailed analysis of application binaries that may impact a successful upgrade. Further, complicating the upgrade decision and process is the fact that prior decisions to postpone upgrades often results in existing versions of software being not just one version earlier than the upgrade but instead many versions behind.
Existing system analysis and upgrade tools are not fully effective in allowing system operators and software upgrade providers to understand the effects and risks associated with performing a software upgrade on a particular computer system. For example, some hardware and software inventory tools have been developed that work to create an inventory of hardware and software in a computer system. These inventory tools create a large volume of general information or metadata for a system that is often too large in volume and too general in nature to be readily used in planning or analyzing a software upgrade. Binary analysis tools have also been developed for use in planning an upgrade. One such tool compares a binary with the new or upgraded software to provide a verification or determine a relatively low risk that the binary will operate or run with the upgraded software. While useful on a case-by-case basis, this tool does not quantify the binaries on a system or provide analysis of binaries that are not verified as compatible (i.e., higher or medium risk binaries). Other binary analysis tools act to quantify binaries on a computer system, such as by providing a total number of binaries, a number of safe or very low risk binaries, and a number of at-risk or higher risk binaries. However, the wealth or volume of information may overwhelm a system manager and not be particularly useful in deciding whether to perform an upgrade. For example, the total number of binaries in a departmental data center environment may be fifty to one hundred thousand or more and at-risk or medium risk binaries may number well into the thousands (even for relatively simple upgrades). This large, raw number of potentially incompatible or affected binaries is often simply unmanageable by a software customer and often results in the customer making the decision to not perform an upgrade because the reward of improved system performance does not appear worth the potential affect on built binaries.
Hence, there remains a need for an improved method and/or system for analyzing and defining the effects of a software upgrade on an existing computer system and existing binaries. Such a method and system would preferably function to better quantify the impact of an upgrade on application binaries and, significantly, to qualify such impact in a manner that assist a software customer in deciding whether or not to perform a software upgrade. In some cases, the method and system would further function to identify particular binaries or groups of binaries that can be revised to better perform the upgrade and would also report binary impact analysis results in a user-friendly manner to facilitate informed decision processes by a software customer.